ProfilesView "New profile" button (previously aria-disabled per V-184a)
now opens an inline modal with name + description + archetype fields.
On submit calls existing client.profiles.create() SDK accessor;
refreshes list on success; surfaces server errors inline on failure
(tier-cap, duplicate name, validation).

Modal:
- Name required (1-120 chars, matches CreateProfileRequest schema), autofocus
- Description optional (500 char max, textarea)
- Archetype select with single LOCKED_ARCHETYPE_ID option today;
  disabled when KNOWN_ARCHETYPES.length < 2; forward-compatible
  for V-136-style archetype expansion
- Backdrop click + ESC close (gated on !submitting)
- Cancel + Create buttons, submit disabled on empty/submitting
- role=dialog + aria-modal=true; brand-aligned (oxblood + slate)

No new deps. Tailwind tokens + custom @layer components cover
all styling. Inline component in ProfilesView.tsx.

Visual verification pending Tauri dev run (autopilot can't open
the desktop window). Patterns are standard React + Tailwind idioms;
founder visual review on next tauri:dev is the canonical check.

V-239 next: tier-aware enforcement display consuming V-237
/v1/account/me via SDK regen.

Verify: typecheck/lint/format clean; 722/722 tests across 75 files
(unchanged — GUI client has no test suite; backend tests pass).

Cross-platform OS keychain storage for customer API keys via keyring
crate v3. macOS Keychain / Windows Credential Manager / Linux Secret
Service or KWallet — auto-selected per-platform.

Three Tauri commands (secret_save / secret_load / secret_delete) wrap
keyring; service identifier matches Tauri bundle id so OS-native UI
surfaces secrets under app identity.

settings.ts reworked: apiKey → keychain via invoke; baseUrl stays in
settings.json. Pre-V-241 customers: transparent migration on first
loadSettings() — apiKey copied to keychain, JSON rewritten without it.

Two Rust unit tests lock the namespace format + service-id-vs-bundle-id
invariant.

Per founder direction 2026-05-06 autopilot grant: T3 decided
autonomously + documented in D-2026-05-06-01. Alternatives considered:
Tauri Stronghold (added complexity), plaintext (current pre-V-241,
acknowledged but not customer-trust-suitable), custom encrypted-blob
(reinvents keyring-rs poorly).

Verify: typecheck/lint/format clean; 722/722 tests. Rust build +
keychain integration pending V-244 CI + tauri:dev per-platform.

  Drift guard for the Tauri-side Rust source. Skips generated
  gen/schemas/*.json.

  - build.rs: thin tauri-build invocation.

  - Cargo.toml: driftstack-gui 0.0.1 MIT non-publish + lib triplet
    (staticlib / cdylib / rlib) + Tauri 2.0 + 4 plugins (shell +
    store + fs + V-243/D-2026-05-06-03 updater + V-328 deep-link)
    + V-241 T3 #1/D-2026-05-06-01 keyring-rs v3 (apple-native +
    windows-native + sync-secret-service) + custom-protocol default
    feature.

  - rust-toolchain.toml: V-240 channel=1.95.0 + profile=minimal +
    components=[clippy, rustfmt] hard pin (README 'Rust 1.95+' soft
    floor → rustup auto-install).

  - src/main.rs: thin entry + windows_subsystem cfg_attr non-debug
    + driftstack_gui_lib::run() invocation; bulk lives in lib.rs so
    it can be built as a library for tests + bound from iOS / Android
    targets.

  - src/lib.rs: V-241 T3 #1 keyring backend with KEYRING_SERVICE
    'dev.driftstack.gui' + KEYRING_USER 'default' single-account +
    Tauri Builder with 5 plugins (shell + store + fs + V-243 updater
    + V-328 deep-link) + 4 commands (ping + secret_save + secret_load
    + secret_delete) + idempotent secret_delete NoEntry → Ok(()) +
    2 namespace-logic tests (keyring_user_prefix_is_stable +
    keyring_service_matches_tauri_bundle_id).

  - capabilities/default.json: 8 core/store permissions + fs:scope
    $APPDATA/recordings/** + 6 fs:allow-* (read-text + write-text +
    remove + mkdir + exists + read-dir) + updater:default +
    shell:allow-open 3-URL allow-list (localhost:5173 + app +
    app-staging).

  - tauri.conf.json: Driftstack 0.0.1 + identifier dev.driftstack.gui
    + frontendDist ../dist + devUrl localhost:1420 + 1 main window
    (1280×800 / min 960×600 / Overlay titleBarStyle / hiddenTitle /
    #0b0f14) + 5-target bundle (app/dmg/nsis/appimage/deb)
    DeveloperTool + macOS minimumSystemVersion 12.0 +
    Entitlements.plist + V-243 updater endpoint github releases
    latest + $TAURI_UPDATER_PUBKEY placeholder + V-328 deep-link
    scheme 'driftstack' desktop-only.

7 new tests pass on first try.

…+ service + tests)

Tier-3 verdicts LOCKED 2026-05-17 (orchestrator handoff post-AUTO #1).
All 5 design-doc questions resolved:

  Q1 encryption key:        REUSE MFA_ENCRYPTION_KEY
  Q2 audit log fingerprint: NO (no last-4-chars fingerprint in audit)
  Q3 team-scope:            account_owner-only (members USE, can't SET)
  Q4 quota visibility v1.0: NO (Anthropic dashboard is authoritative)
  Q5 llm_billing_mode:      DEFER to v1.1 migration (keep v1.0 tight)

This commit ships the foundation layer (~600 LOC, 18 tests):

1. Migration 0041_byok_anthropic_key_storage.sql + _journal.json:
   ALTER TABLE accounts ADD 3 NULL columns. Single bytea is canonical
   `[12 bytes IV | 16 bytes auth tag | N bytes ciphertext]` so GCM
   parameters travel with the ciphertext (self-contained roundtrip).

2. Drizzle schema entry on accounts table — typed `Buffer` for the
   bytea via customType.

3. apps/server/src/lib/byok-anthropic-encryption.ts:
   AES-256-GCM encrypt/decrypt + the BYOKAnthropicKeyPlaintext brand
   type so the compiler refuses to pass the decrypted plaintext into
   log/error/audit paths without an explicit unsafe cast.
   looksLikeAnthropicKey() prefix check used at PUT time.

4. apps/server/src/services/byok-anthropic.ts:
   BYOKAnthropicRepo interface + BYOKAnthropicService (set / clear /
   getPlaintext / getMetadata / touchLastUsed) + InvalidKeyFormatError
   + InMemoryBYOKAnthropicRepo for tests + dev mode.

5. apps/server/src/db/byok-anthropic-repo.ts:
   DrizzleBYOKAnthropicRepo — UPDATE-on-accounts-row (no separate
   table; design-doc shape). touchLastUsed deliberately does NOT bump
   updated_at (application-side observation, not customer mutation).

6. apps/server/src/lib/config.ts:
   Canonical env var is BYOK_ANTHROPIC_FALLBACK_KEY per orchestrator
   handoff; existing DRIFTSTACK_ANTHROPIC_FALLBACK_API_KEY accepted
   as a deprecation-window alias so dev shells with the old name
   keep working.

7. 18 unit tests: encryption round-trip + IV-randomness + empty-
   plaintext reject + short-blob reject + GCM tamper detection +
   key-mismatch reject + 32-byte key validation + prefix validator +
   service set/get/clear/touch/rotation/per-account-isolation.

Follow-up slices (next commit, to stay under Rule R 50-file ceiling):
bootstrap wiring + AppDeps slot + 4 route handlers + audit-log entries
+ dashboard /settings/byok-anthropic page + AgentRuntime resolution-
priority change (header → customer-key → fallback).

Reference: docs/internal/byok-anthropic-key-storage-design.md

…essionsRepo

Schema LOCKED 2026-05-17 by orchestrator handoff post-AUTO #1.

Migration 0042_agent_sessions.sql + _journal.json:

  CREATE TABLE agent_sessions (
    id                      text PRIMARY KEY,
    account_id              uuid NOT NULL
                              REFERENCES accounts(id) ON DELETE CASCADE,
    driftstack_session_id   text NULL,
    status                  text NOT NULL CHECK
                              (status IN ('active','paused','closed')),
    transcript              jsonb NOT NULL DEFAULT '[]'::jsonb,
    token_budget_total      integer NOT NULL CHECK (total > 0),
    token_budget_remaining  integer NOT NULL CHECK (remaining >= 0),
    closed_reason           text NULL,
    created_at              timestamptz NOT NULL DEFAULT now(),
    updated_at              timestamptz NOT NULL DEFAULT now(),
    CONSTRAINT agent_sessions_remaining_le_total
      CHECK (remaining <= total)
  );

  CREATE INDEX agent_sessions_account_id_idx
    ON agent_sessions(account_id);
  CREATE INDEX agent_sessions_active_idx
    ON agent_sessions(status) WHERE status = 'active';
  CREATE INDEX agent_sessions_driftstack_session_id_idx
    ON agent_sessions(driftstack_session_id)
    WHERE driftstack_session_id IS NOT NULL;

Design rationale (founder-locked):

  - text PK (`agt_<uuid>`) matches existing InMemoryAgentSessionsRepo
    minting; visible "agt_" discriminator carries domain meaning in
    logs (vs raw uuid).
  - CHECK over a status enum lets future status additions ship as a
    single constraint-edit migration, not the full Postgres-enum-type
    dance.
  - jsonb transcript mirrors recipes.intent_log; append-only growth.
  - Partial indexes on hot/sparse paths — active-only is the dashboard
    list query; driftstack_session_id IS NOT NULL is the harness
    "which agent_session is driving this browser session?" lookup
    (most rows are NULL).
  - ON DELETE CASCADE — no orphan agent_sessions if customer deletes
    their account (matches account-mfa / recovery-codes lifecycle).
  - remaining ≤ total CHECK at the DB layer — belt-and-suspenders
    against concurrent debit drift; single UPDATE statements are
    atomic but the constraint catches any future code path that
    skips the read-modify-write discipline.

Drizzle schema entry in schema.ts (`agentSessions` table) +
`DrizzleAgentSessionsRepo` in db/agent-sessions-repo.ts. Same surface
as the InMemory variant (create / get / listByAccount /
appendTranscript / debitTokens / closeWithReason); read-modify-write
UPDATEs with the CHECK constraint as the DB-side debit guard.

Bootstrap wiring (constructing DrizzleAgentSessionsRepo +
AgentRuntime in prod, flipping the /v1/agent-sessions/* activation
gate) is the follow-up slice — pairs with AI-B1.b real Claude wire
since flipping the gate without the real LLM would give customers a
stub-decomposer experience worse than 503.

Design doc refreshed:
  - AI-A.b row moves from "pending" to SHIPPED (this wave)
  - AI-A.c row moves from "pending" to SHIPPED (this wave)
  - AI-B1.c (BYOK per-customer storage) moves to SHIPPED — pointed at
    yesterday's two-commit foundation + routes pair (e552381 + 994386c)

…VED AS WRITTEN)

V-820 fleet-nodes SQL design APPROVED AS WRITTEN 2026-05-17 by
orchestrator handoff post-AUTO #1. Migration + Drizzle schema + repo.

Migration 0043_fleet_nodes.sql:

  CREATE TABLE fleet_nodes (
    id uuid PRIMARY KEY DEFAULT gen_random_uuid(),
    public_key_base64url text NOT NULL,
      CONSTRAINT fleet_nodes_public_key_format CHECK
        (public_key_base64url ~ '^[A-Za-z0-9_-]{43}=$'),
      CONSTRAINT fleet_nodes_public_key_unique
        UNIQUE (public_key_base64url),
    display_name text NOT NULL,
    region text NOT NULL,
    hardware_class text NOT NULL,
    registered_at timestamptz NOT NULL DEFAULT now(),
    last_seen_at timestamptz NULL,
    revoked_at timestamptz NULL,
    revocation_reason text NULL
  );

  CREATE INDEX fleet_nodes_region_idx
    ON fleet_nodes(region) WHERE revoked_at IS NULL;
  CREATE INDEX fleet_nodes_last_seen_at_idx
    ON fleet_nodes(last_seen_at DESC) WHERE revoked_at IS NULL;

Design choices (founder-locked verdicts):

  - region + hardware_class as free-form text (NOT enums) — operator
    set, CHECK enum feels too rigid for the operational table.
  - public_key_base64url uniqueness via UNIQUE constraint —
    two nodes sharing a keypair would defeat per-node revocation.
  - 44-char format constraint (43 base64url chars + 1 '=' pad) — RFC
    4648 §5 for an Ed25519 32-byte public key.
  - Soft delete via revoked_at — row stays so audit trails survive.
  - Partial indexes on the two hot paths — region scheduler reads +
    last-seen-at dashboard sort — both filter WHERE revoked_at IS NULL.

Drizzle schema entry on `fleetNodes` table (schema.ts) +
`DrizzleFleetNodesRepo` (db/fleet-nodes-repo.ts) implements the
`FleetNodesRepo` interface (just `getPublicKey`) AND adds operator-
surface methods on the concrete class (register / revoke /
touchLastSeen / getDetail / listActive / listActiveByRegion). Adding
those to the interface would require the InMemory variant to grow
the same shape; the operator routes only run against the Drizzle
path so this asymmetry is intentional.

Once this lands + bootstrap wires DrizzleFleetNodesRepo (next slice):
  - /v1/fleet/events activation gate (ae670c8) flips from disabled
    503-stub to wired 503-stub (still pending WebSocket handler +
    fastify-websocket plugin + Cloudflare AOP).
  - Agent 1's V-820.B.1.b mTLS endpoint can register its first
    production fleet node + verify the auth path end-to-end.

Reference: docs/internal/fleet-nodes-sql-migration-design.md

…ch prod systemd+node)

Verdict LOCKED 2026-05-17 (orchestrator handoff post-AUTO #1).
Rationale (founder-locked):

  - Matches prod systemd+node reality at /opt/driftstack/api.
  - deploy-bridge.sh proven across 10+ Wave 1062 prod deploys.
  - 1h autopilot rewrite vs 3-4h operator-paired Docker install.
  - Founder's personal-Mac Docker is dev-only (and was just stopped),
    unrelated to prod path.
  - Future Docker migration (Option A) stays an option as a Q3 2026
    hardening project once paid customer traffic is online.

What changed in .github/workflows/deploy.yml:

  - Dropped: Docker buildx + build-push-action + ghcr.io push, the
    `docker-compose pull / up -d --remove-orphans` deploy step, the
    DEPLOY_DOTENV_BASE64 secret (env stays on the host at
    /opt/driftstack/api/.env; rotation is SSH-write, not GH Action
    payload — narrower secret-leak surface).

  - Added: SSH key configuration step on the runner; the staging /
    production jobs each `bash scripts/deploy-bridge.sh staging /
    prod`. deploy-bridge.sh stays the SOURCE OF TRUTH (used both by
    manual operator deploys and by this workflow). Single execution
    path; no Docker drift between dev and CI.

  - Preserved: Sentry source-map upload (clean CI build runs in the
    source-map-upload job, separate from the deploy path); manual
    approval gate on the production environment via GH environment
    settings.

Required secret rotation (one-time founder action):

  - Old: HETZNER_HOST / HETZNER_USER / HETZNER_SSH_KEY /
         DEPLOY_DOTENV_BASE64 (set per environment).
  - New: HETZNER_DEPLOY_SSH_KEY (private key with deploy-scoped access
         to root@<prod|staging>). Single secret, both environments.
         See docs/founder-actions/v278-hetzner-deploy-keys.md.

Verdict-design doc updated to record the locked outcome + reference
the implementation commit.

Reference: docs/internal/2026-05-16-deploy-yml-verdict-design.md +
docs/internal/2026-05-15-deploy-pipeline-mismatch.md.